home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98b.txt / 000096_icon-group-sender _Fri Jun 19 12:38:53 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  10KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id MAA22260
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Fri, 19 Jun 1998 12:38:53 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA13686; Fri, 19 Jun 1998 12:38:43 -0700
  7. From: pygmy@eskimo.com (Frank Sergeant)
  8. To: icon-group@baskerville.CS.Arizona.EDU
  9. Subject: using Icon for database application
  10. Date: Fri, 19 Jun 1998 12:11:28 -0500
  11. Reply-To: frank.sergeant@pobox.com
  12. Message-Id: <Avpi1Yv1ukQG084yn@eskimo.com>
  13. Lines: 186
  14. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  15. Status: RO
  16. Content-Length: 8752
  17.  
  18.      I was in the process of attempting to pick my new
  19. language for a particular application when the July '98
  20. _Linux Journal_ arrived containing the Jeffery/Mohamed
  21. article "A Glimpse of Icon".  I enjoyed the article and
  22. that led to reading the Linux Gazette article and various
  23. Icon Newsletters, archived mailing list, etc.  I'm now
  24. reading the 1983 edition of _The Icon Programming Language_
  25. (Icon v. 5).
  26.  
  27.      I'd like to discuss some of my questions and concerns
  28. related to Icon and its use in my application in hopes of
  29. hearing your comments and suggestions.  Please feel free to
  30. email me or to post to the list as you prefer.
  31.  
  32.      I maintain a medical accounts receivable application
  33. that is installed in 12 or 13 small medical offices.  Two of
  34. us are involved: Hal for sales (if you can call it that) and
  35. me for the programming and technical support.  I took it over
  36. nearly 4 years ago and have been improving it and cleaning
  37. it up since then.  It is written in Clipper (the dBASE or
  38. xBASE language) and consists of around 150,000 lines of
  39. source.  It runs under DOS (or a DOS box in Windows).  More
  40. work is needed to clean it up further to make it easier to
  41. maintain.  Our typical customer has two or three PCs and
  42. runs under a "file server" model with either DOS/Lantastic
  43. or with W95 for the networking.  Thus, all workstations
  44. access the database files (*.DBF) and index files.  (Any
  45. workstation crashing puts the data files on the server at
  46. risk.)  I am interested in moving more toward a
  47. "client/server" model where all access to the data files is
  48. handled by a process on the server ("put all your eggs in
  49. one basket then _watch_ the basket").  I am not interested
  50. in buying or having our customers buy a commercial SQL
  51. database system.  I plan to handle the programming of the
  52. data access myself.  One obvious decision to make is whether
  53. to do the cleaning up in Clipper before I convert or to
  54. convert and clean up as I go.
  55.  
  56.      Here are the reasons I am considering changing
  57. languages (to the degree I know my own thinking):
  58.  
  59.      1. Protect the data better by restricting its access
  60.         to a single program on the server.
  61.  
  62.      2. Reduce network traffic (by not dragging the database
  63.         and index files over the ethernet) to speed up
  64.         the application.  This is not a problem on an
  65.         ethernet, as it is fast enough, but opens the door
  66.         to making the application usable even over a modem.
  67.  
  68.      3. By going to a 32-bit Windows program we get out of
  69.         the 16-bit Windows step child environment.  My
  70.         feeling is that 16-bit applications are more likely
  71.         to suffer from Windows bugs than 32-bit "native"
  72.         applications.
  73.  
  74.      4. Offering a "Windows" version of the program might
  75.         occasionally attract a customer who would not
  76.         consider a plain DOS application -- and might help
  77.         keep current customers.
  78.  
  79.      5. Open the door to working in a mixed operating system
  80.         environment.  In particular, for even better
  81.         reliability, customers could use a Linux box as the
  82.         server.
  83.  
  84.      6. Our history of sales has been dismal.  Still, we
  85.         have our core of loyal customers that use it year
  86.         after year and cheerfully pay our small ($300/year)
  87.         annual maintenance fee.  I am in this for the long
  88.         run.  If we never make another sale, I intend to
  89.         support these customers forever.  However, I need to
  90.         do this as efficiently as possible, as I need to
  91.         take on other work to keep eating.  So, platform and
  92.         vendor independence seem like worthy goals.  This
  93.         seems to rule out VO (CA-Visual Objects, supposedly
  94.         the Windows-based successor to Clipper) and Delphi
  95.         which run only on Windows.  Perhaps I should
  96.         consider Java, but I think I am suffering from hype
  97.         poisoning.  Python and Perl sound good to me
  98.         primarily because of the delightfully literateness
  99.         of the Pythona Perl books' authors.  I'm agreeable
  100.         to the idea that Perl's syntax is too muddy.  Perl
  101.         still looks good.  (Can anyone comment on the
  102.         various tradeoffs between these languages and Icon?)
  103.  
  104.  
  105. Icon questions (or comments)
  106.  
  107.      1. How do you think all this fits with Icon?
  108.  
  109.      2. I gather Windows Icon can make a normal looking
  110.         Windows application (rather than a Motif-ish
  111.         application) and that I probably could figure out
  112.         how to do this by reviewing the source code for Wi.
  113.         Does that sound reasonable?  Would _Graphics
  114.         Programming in Icon_ help?  (I'm not interested in
  115.         drawing pictures, etc, just in the UI part.)
  116.  
  117.      3. How fast is an Icon application?  For example, I ran
  118.         the Python Megawidgets demo program that puts up a
  119.         screen full of entry fields (Pentium 90 with 48
  120.         MB RAM) and the fields rippled slowly onto the screen
  121.         rather than just popping up instantly.  I'm afraid that
  122.         would be too slow.  Many of our customers' machines
  123.         are not even up to a P90/48MB, e.g. '486 8MB.  (Some
  124.         even use slow '386s and one uses one or two
  125.         '286s, but I would expect they would be willing to
  126.         upgrade.)  My point is the application must be fast
  127.         enough on moderate hardware as I can't expect all
  128.         customer machines to be the latest and fastest.
  129.  
  130.      4. How big would the .EXE file be?  From a newsletter,
  131.         I understand there is the 200K or 300K overhead for
  132.         the Icon interpreter.  How does .EXE file size grow
  133.         after this?  (I imagine this is hard to answer, but
  134.         perhaps you can give me some idea.)  Currently our
  135.         .EXE is about 850K, so I can live with that size,
  136.         but would prefer smaller.
  137.  
  138.      5. Is a sockets interface only available for Unicon or
  139.         is it also available for Wicon?  I would hope the
  140.         client programs on the workstations could connect
  141.         via sockets to the server running either on a
  142.         Windows 95 or Linux machine.  The client machines
  143.         would almost certainly be W95 machines.  If sockets
  144.         are not built in to Icon, how hard is it to make
  145.         calls to the Win32 system?  How about to routines
  146.         produced by MSVC or Borland C?  Perhaps I could
  147.         write the socket access routines in C and call them
  148.         from Icon?
  149.  
  150.      6. So far I haven't been able to track down Idol.  A
  151.         url or two for Idol on the web site seemed to give
  152.         an "invalid" message.  Since I had also been
  153.         considering Python for this application, it seems I
  154.         should consider using Idol if I use Icon, right?
  155.  
  156.      7. I currently make extensive use of Clipper's "ragged
  157.         arrays".  These are essentially lists where the
  158.         elements can be of any type including other lists.
  159.         It looks like Icon's lists would just drop in and
  160.         work the same.
  161.  
  162.      8. The current app is about 150,000 lines (over 100
  163.         source code files).  How does Icon handle
  164.         applications of this size?  I think the app is currently
  165.         more complex than is required.  All we do, really,
  166.         is keep track of, display, modify various lists --
  167.         lists of doctors, patients, insurance companies,
  168.         charges, paygments, and such.  (How hard can it be?)
  169.  
  170.      9. The data, ignoring index files, probably runs 2 to
  171.         10 MB in most offices.  At the larger sizes, much of
  172.         the data is relatively inactive and could be rolled
  173.         out to archives.  On a modern machine, all the data
  174.         would fit in RAM.  I am not talking about an
  175.         application with gigabytes of data and 200
  176.         workstations and multiple servers.  We currently use
  177.         dBASE style .DBF files.  These have fixed width
  178.         fields.  As an experiment, I converted some of our
  179.         data files to variable width, delimited files
  180.  
  181.            Smith, George|1234 W. 17th Street|etc|etc|etc
  182.  
  183.         and was surprised to find it reduced file size by
  184.         about two-thirds.  I'm not sure this is typical, but
  185.         it looks like going to variable width fields would
  186.         save a lot of space, making the data fit even more
  187.         easily into RAM, reducing the time of reading from
  188.         disk, etc.  The cost would be the slower parsing of
  189.         records to locate the individual fields.  Any
  190.         thoughts about the tradeoffs here?
  191.  
  192.     10. I have been very impressed with Bertrand Meyer's
  193.         _Object Oriented Software Construction_.  Can anyone
  194.         comment on the differences between Eiffel and Icon,
  195.         that is, why I might prefer Icon over Eiffel, etc?
  196.  
  197.  
  198.      All comments, suggestions, corrections gratefully
  199. received.
  200.  
  201.  
  202.   -- Frank
  203.   frank.sergeant@pobox.com
  204.